Lighting systems for areal illumination typically comprise (1) a set of “luminaires” (light fixtures comprising mounting hardware and one or more light-emitting elements such as incandescent or fluorescent bulbs or arrays of light-emitting diodes [LEDs]), together with (2) one or more sensor elements (motion sensors, light sensors, and the like), (3) control devices (such as dimmers and switches), and (4) power drivers to set the output light level of each luminaire as a function of sensor outputs and control device settings. Such systems can range in complexity from a single wall switch and bulb to commercial building lighting systems comprising hundreds of luminaires, sensors, and control devices. An example of such a lighting system for commercial building lighting is disclosed in co-owned and co-pending U.S. patent application Ser. No. 12/538,806 which is incorporated herein by reference.
Sensor devices such as motion sensors often sit quiescent for extended periods of time and change state only for brief periods of activity. Control systems may need to respond rapidly to these “events,” but it is undesirable for a control system to use resources to continually check for the occurrence of an event. For this reason, digital control systems that use such sensors often respond to these sensors via “interrupts.” That is, instead of continually polling the sensor to check for an event (and thereby wasting potentially valuable computational resources), the sensor device is configured to generate an “interrupt” signal, typically wired to a dedicated terminal on the controller. Only when an interrupt signal is received does the controller take any action with respect to the sensor (such as, for example, turning on one or more lights in response to detected motion). Typically, a specific interrupt response subroutine is run as soon as possible when the interrupt is received, interrupting any other data processing that may otherwise be in progress. Response to interrupts is often time-critical, and it can be important to respond as nearly as possible in “real time.” If there are multiple possible interrupts requiring response, an interrupt queue may be established, and interrupts are typically processed on a first-in-first-out basis from the interrupt queue, with normal data processing resuming when the queue is empty and all currently active interrupts have been processed.
Another example of a special activity embedded within normal processing can be found in the use of “escape sequences” or “control sequences.” These were first used in digital text communications devices where such escape sequences were used to embed non-printing functionality such as device control, font changes, or other mode changes into a character stream. Characters that were to be interpreted with a special meaning such as “change to italic font” were preceded and/or followed by a special character to indicate the special interpretation. The use of escape sequences was subsequently adopted in digital communications with all sorts of physical devices to embed special control functions and modal changes into normal data streams. Note that escape sequences are not interrupts. They implement mode changes that change the interpretation of particular characters in a character data stream, but they are not in any way event-driven. Escape character are inserted in an orderly fashion to indicate that, after processing one set of characters, a mode change should then be implemented to process the next set of characters. Interrupts, on the other hand, are used to process asynchronous events that can occur independently of “normal” data transmission and processing.
Another particular example of control sequences is the use of “XON/XOFF” for software control of data flow. When the receiving end of a data link is incapable of processing incoming data as fast as the transmitting end is capable of sending it, the receiving end sends “XOFF” to the transmitting end which then temporarily suspends data transmission until it is ready to accept data again, at which time the receiving end sends “XON” to indicate that it is again ready to accept data. For example, a computer may be able to send data to a serial printing device much faster than the device can format the data and output it to paper. The printing device may include a buffer to store data ahead, but even that buffer may have a finite capacity which can be exceeded when data is being transmitted faster than the buffer can be emptied. When the buffer is full, the printer transmits “XOFF” to indicate that it can no longer accept data; when there is again sufficient space in the buffer to store data, the printer transmits “XON,” and the source computer resumes transmission of data.